IBIS Macromodel Task Group

Meeting date: 17 September 2019

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                              Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Kumar Keshavan
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Stephen Slater
                              Maziar Farahmand
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None

-------------
Review of ARs:

- AR: Randy Wolff to draft a response to the BIRD198 authors.
  - Done.

- Arpad Muranyi asked if there should be a formal AR for Michael and Randy to invite
  DDR memory and controller vendors to comment on new protocols.  We agreed to make
  that an AR. Randy said he had asked for feedback within Micron but had none yet.

[AR] Randy Wolff and Michael Mirmak to invite DDR memory and controller vendors to comment on new protocols.

-------------------------
Review of Meeting Minutes:

Arpad Muranyi asked for any comments or corrections to the minutes of the September 10
meeting.  Walter Katz. moved to approve the minutes.  Randy Wolff seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD198.1:
Walter Katz asked if we had a response from Japan. Arpad Muranyi and Randy Wolff said
there had been none.

DC_Offset BIRD:

Walter Katz showed "DC_Offset and VrefDQ". This was his third presentation on the topic.

Slide 2:
Walter felt slide 2 gave a good representation of DDR5 SDRAM.  VrefDQ is voltage set
by a register, with 100 to 200 settable values.  The values would be between VDDQ and
VSSQ with approx 0.5mV step size.  The source might be a tapped series of resistors.
JEDEC has requirements for the memory but not the controller.  VrefDQ can be thought
of as the reference.  The controller picks the reference in a training sequence,
approximating VrefDQ to the DC offset.  The hardware sees a DQ signal, the midpoint of
which is the DC offset.  A differential amplifier calculates the difference between
VrefDQ and the waveform.  The software subtracts DC offset from DQ, by subtracting
VrefDQ.  The Rx out will be relative to VrefDQ.  The EDA tool can offset by DC offset
or VrefDQ, but VrefDQ is Model_Specific.

Fangyi Rao asked if VrefDQ would be an In parameter.  Walter said he would implement it
as a register number, and it would be an Out.  Ambrish Varma asked where the value for
an In parameter would come from.  Fangyi said it could come from a training sequence.
Walter said in hardware the controller sets VrefDQ, and AMI models should do likewise.
The model is likely to know the non-linearity of VrefDQ better than what the standard
would have.  Randy Wolff felt that knowing Vref would be better than knowing the offset.
Transmitters that are not symmetric might see a greater difference between DC offset
and VrefDQ.  Walter said even if symmetric, the Tx would sweep up and down to pick
a value near the middle.  It may not be a perfect middle point due to the discrete
steps.  A large gain could be a problem due to saturation.  The EDA tools wants to
know VrefDQ. A Reserved_Parameter would be good.

Fangyi noted that the slide showed no gain. He asked what the amp output would look
like relative to ground.  Walter said JEDEC only describe it as one way to implement
an Rx, not THE way.  Other receivers could differ.  Fangyi said the Rx output would not
be referenced to VrefDQ, it would be referenced to ground, and the Rx output would not
be physical.  Walter did not agree.  Radek said having DQ by itself was not meaningful,
it had to be referenced to something.  Fangyi said on an scope it would be reference
to ground.  Walter accepted that.  Fangyi said Rx out could not be compared to DQ only
because their centers were side by side.  It was a convenience.

Slide 3:
Walter said the controller would pick a VrefDQ between the high and low error limits.
AMI_Init could pick a value closer to DC offset. In AMI_GetWave, non-linearities could
be accounted for.

Walter Katz showed EMD BIRD draft 20.

Slide 4:
Walter said in case shown, the controller was in control, not the Rx.  It could control
VrefDQ, Gain, and DFE taps.  JEDEC gave only minimum and maximum values for those.

Slide 5:
Walter said the Rx could tell the Tx those settings, plus eye metrics.  Training could
only test for BER 1e-3 or 1e-4 due to simulation time limitations.  The Rx could
communicate jitter as an impulse response. That could be sent to the Tx.  It could be
done one of two ways:

1) BIRD147, using a file. The impulse response is not small, could impact performance.
2) (Slide 6) A new function argument.

Fangyi asked how crosstalk would come from the Tx.  Walter said the EDA tool accounted
for crosstalk.  Fangyi said the noise would be amplified.  Michael Mirmak said one
of the two must account for crosstalk.  Walter felt the standard for that should be
defined by the vendors, not IBIS.  The impulse response might be the full response.
The more information we transfer, the more approach #2 would be needed.

Fangyi asked if slide 5 applied to both statistical and time domain.  Walter said it
was both. He described ways that might happen.  Fangyi said the Rx would have to wait
some number of bits before reporting eye height.  Walter felt it might be 10,000 UI,
but that was what the hardware would do anyway.  Fangyi said that might take about 10
AMI_GetWave calls.  Walter said synchronizing would not be trivial.  Arpad suggested
that some control for the range of acceptable block sizes would be needed.  Walter said
AMI_GetWave should be able to work with the input regardless of block size.  Arpad said
he would not want to have a problem similar to that seen with samples per bit.

We will continue this topic next week.


Enabling Back-channel in Statistical Mode:
No discussion.


Jitter HF/LF components and jitter amplification:
No discussion.


- Arpad: Motion to adjourn.
- : Second.
- Arpad: Thank you all for joining.


-------------
Next meeting: 24 September 2019 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

